Collection of Tools & Utilities/Collection of Tools and Utilities.iso/graphic/pbmpl91d.zip/PBMPLUS/README.DOS

Text File | 1993-01-08 | 8KB | 173 lines

Disclaimer: This software is distributed WITHOUT ANY WARRANTY; without
even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

PLEASE READ ALL THE INCLUDED README.* AND FAQ FILES BEFORE USING THIS
PACKAGE.

To port pbmplus to dos using the djgpp compiler (gcc/g++), I did the
following:

Configured the makefiles and and pbmplus.h as appropriate (about the
only thing I did was set up to use gcc    with -O2 -funroll-loops and
not to use X-windows color database).  Fixed makefiles to do not
require a special shell (probably ms_sh*.zip package would work to make
it not necessary to fix the makefile).    Added the command aout2exe $*
to turn the final executable into an *.exe.

Added 2 programs not usually in the package:  ppmqvga and pnmcomp
which do vga optimized quantization and image composition, respectively.

Fixed the p?mmerge files to handle *.exe in the 8.3 filename format, and
added ppmqvga and pnmcomp to them.

Build tiff library WITHOUT the g3 support. (I don't think the tiff
binaries use this code, and the compile the g3 statemachine took about
12 megs of memory, or about 45 minutes for that one file, since I only
have 8 megs and my hard drive was thrashing pretty horendously).

Apply a fix to the djgpp libraries.  First made a modified startup code
(set crt0new.s) and fix_io.c.  Added fix_io.o to libc.a and used the
crt0new.o instead of crt0.o that came supplied with djgpp.    These modules
basically lets us use binary files using dos pipes which normally can't be
done.

make. Takes about 2 hours on my 386/sx-16 :-<

A zip of the stubbed exe's for the complete package is about 1.86 megs
(using info-zip 1.9).  As a result, I will only be uploading the merged
binaries (see below).

use cawf package to make man pages.


The package (be it zip, zoo, whatever) will consists of the following:

bin/p?mmerge.exe                       executables
bin/go32.exe                           The dos-extender
bin/emu387                             387 emulator for those without
bin/*.                                   script files that *may* work under
                                       certain dos shells (4dos, ms_sh)
man/*.man                               cawfed up man pages
src/fix_io.c                           function to make io-default to binary
src/crt0new.s                           new startup code to call above function
newsrc/*.c                               src for progs not usually in pbmplus
newsrc/*.1                               nroff files for above
patch/*.dif                            few diffs (makefiles and pbmplus.h)
readme                                   Jef's readme
readme.dj                               DJ's readme for djgpp
readme.dos                               this file
faq                                    faq file for djgpp

This port of PBMPlus was compiled using the djgpp package, a port of
the Free Software Foundation gcc/g++ compiler.    More info can be found
in readme.dj.  This port REQUIRES a 386 processor or better as it uses
32-bit code.  Due to the nature of the dos-extender, DPMI (and hence
ms-windows).  More info on this in the readme.dj and readme.1st files.

To install, but the file go32.exe somewhere in your path.  This is the
actuall dos extender.  While I could have built the binaries with the
extender built in, that does 2 things: makes it harder to upgrade the
extender (when a new one comes out, just replace it), and makes the
binaries larger.  The code that calls go32.exe is much smaller.
You need to set an environment variable GO32TEMP to point to a temporary
directory where you would like go32 to put its paging file (go32 will
use virtual memory when you run out of real memory).

Something like:
set GO32TEMP=c:\tmp
is appropriate.  BE SURE THE DIRECTORY EXISTS!!

Put the other binaries (p?mmerge.exe) somewhere useful.

Since the compiled binaries take up so much room, I have decided to only post
the merged binaries.  If you really want to install the normal binaries,
the package builds easily with my patches.    Just get the official pbmplus
package from export.lcs.mit.edu (18.24.0.12).

On unix systems, you can do what is called a 'link' to a file. Essentially
what this does is gives the same file different names.    When the file is an
executable, the name returned by argv[0] is what ever name you invoked it by.
Some programs can examine argv[0] and change their functionality as a result.
compress/uncompress/zcat does this.  All three programs are identical (and
on many systems, the exact same file with multiple links).    Pbmplus uses
this functionality to make smaller 'merged' binaries.  Instead of compiling
each program with main(), each program in compiled with filename_main().
A dispatch program (the p?mmerge.c file) calls the appropriate filename_main()
based on what is in argv[0].  The result is you get one binary, slightly
bigger than any individual binaries, but smaller than all of them put together
becuase you are only linking in one copy of fprintf(), one copy of fopen(),
one copy of ppm_readfile(), etc.

Now, since dos does not support links in its filesystem, you have to result
to copying to get the functionality of the programs.

For example, if you want to take a 24-bit Targa file and quantize it to an
8 bit gif file for viewing, you would do the following:

copy ppmmerge.exe tgatoppm.exe
copy ppmmerge.exe ppmqvga.exe
copy ppmmerge.exe ppmtogif.exe
tgatoppm my.tga | ppmqvga | ppmtogif > my.gif

Of course, if you use a certain utility a lot, you keep that one around.
If you occasionally need a certain functionality, you can copy the merged
binary to the appropriate name, use it, then delete it.  If you want to
keep the entire ppmplus package on line, I would recommend building it
yourself.  Takes about 4 megs to keep all the stubbed exe's around. What
I do is keep unmerged copies of the files I use all the time and the
p?mmerge files.  When I occasionally come across something I don't have,
I can use the merged binary.  You can usually figure out which merged binary
to use by the name of the program you want.  Any program that handles
multiple p?m types will be in the higher ranking of the merged binaries.
ie, pbmtopgm is in pgmmerge, pgmtoppm is in ppmmerge, etc

Known Bugs:
I only know of 2 bugs in the package.

The first are the tiff based binaries.    While tifftopnm and pnmtotiff will
read each others files, I can't get either to work with files produced with
Graphics Workshop.    This is a result more of the tiff UNstandard than anything
else.  Surprisingly, CompuSHOW will handle tiffs produced by both GWS and PMB+
with no problem.  Go figure.

The second is under DESQview (at least version 2.42).  Since way that the
dos extender changes stdin to handle BINARY files will cause a hang of a
session if you don't redirect input into the file.

Example:
you can always to the following:

ppmtogif my.ppm > my.gif
or
ppmtogif < my.ppm > my.gif

If you try the following from outside DV:

ppmtogif > my.gif

It will read from the keyboard, and you could enter a ppm file by typing it in
(why you would want to I don't know).  If you try that from inside DV, it
will hang that window and you will have to manually close it (not even
control-c will break out of it).  Usually, the only time this will cause a
problem is when you write a pipeline and forget to supply the initial file.
If anyone uses a DV specific shell (one that supports multiprocessing, and
uses true pipes instead of intermdiate files), this should work.  I'd be
interested in hearing if it appears any faster than using a ramdrive to hold
the tempfile (this can be controlled by some command shells, such as 4dos,
and command.com as supplied in msdos 5.0 and dr-dos 5.0 and up).

The tiff bug, I'm not too worried about.  It *may* also be a problem with
files produced on a unix system, but I haven't the opportunity to track
down the problem.  The other bug I'm not sure what the cause is, and
it will probably take better programmer than I to fix.

If you have any problems, comments, etc, I can be reached at:

Mike Castle
1204 N. Pine, Apt 5       NOTE: School address.  never know when might change
Rolla, MO 65401           suddenly.

[e-mail]
[e-mail]